👋 @TrySound, are you able to review this change?

It's worth also to upgrade it in 1.* version, because some of the projects depend on this version and it will be hard to upgrade it without breaking of API (i.e. look into gregberge/svgr#654)

Noting that this "Resolves #1488" in the hopes that that magic phrase will close the issue when/if this get merged (I know that works if it's in the description of a PR, guess we'll find out if it works if its in a comment...)

Edit: RIP me - it doesn't

FYI the breaking changes from css-select 3.1.2 -> 4.1.2 changelog (for someone with better knowledge of this codebase to be able to more easily review):

• Several built-in pseudos are now stricter. This aligns them with the CSS spec, but might lead to changes in results.
• In HTML, attributes are now automatically considered case-insensitive, based on the HTML spec. Some selectors might now match more elements.
• Removed strict option.

@underoot This is a breaking change, as it affects CSS selectors in <style> elements, which requires svgo to bump to v3 major. Therefore, patching v1 is not viable.

For Yarn users (in your package.json):

"resolutions": {
  "**/css-what": "^5.0.0"
}

This should be safe to do, as it avoids any of the breaking changes introduced in css-select@4.

This is a breaking change, as it affects CSS selectors in <style> elements, which requires svgo to bump to v3 major. Therefore, patching v1 is not viable.

Given that the changes are related to spec compliance (and the strict option doesn't seem to be used by SVGO) I'd be inclined to disagree. If you're using non-standard CSS selectors I think it's fair that SVGO doesn't support that out-of-the-box, and the fact that it did could be considered a bug. I think it's more important people on older versions of SVGO can easily update, than that a presumably small minority that uses non-standard selectors isn't bothered by an update.

Though of course it's up to the SVGO maintainers to decide.

Edit: RIP me - it doesn't

Did it for you 😉

As this concerns a vulnerable dependency that is also used in the latest SVGO v1, ideally SVGO v1 should also be patched. I'm not sure what the procedure is for updating SVGO v1 though...

@TrySound, do you have any comment in this regard?